Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Vulkan] Initialize wgpu objects from raw handles, part 2 #1850

Merged
merged 1 commit into from
Aug 25, 2021
Merged

[Vulkan] Initialize wgpu objects from raw handles, part 2 #1850

merged 1 commit into from
Aug 25, 2021

Conversation

zmerp
Copy link
Contributor

@zmerp zmerp commented Aug 23, 2021 •
edited
Loading

Connections

#1609

Description

While #1609 was needed to support OpenXR applications, this PR aims to support OpenXR runtime/SteamVR drivers implementations. Instance::from_raw(), Adapter::device_from_raw() and Device::texture_from_raw() are made more flexible to accomodate both use-cases.

Recap:

(With ownership I mean the responsibility of destroying the object)
In a OpenXR game, the instance and device are created by the runtime and owned by the application. The session is created by the runtime using the instance and device and owned by the application. The swapchain textures are created by the runtime and owned by the runtime. Wgpu textures used to access the swapchain are created by the application and the handles are owned by the runtime.
The wgpu textures must go out of scope before destroying the swapchain and session, which must be destroyed before destroying the device and instance. Drop guards are used as barriers to prevent the drop of objects on which Instance and Texture depends on, by keeping a reference to it. The presence or absence of drop guards is used also as flag for deciding if to destroy the underlying Vulkan object (drop_guard == Some for Instance::from_raw(), drop_guard == None for Device::texture_from_raw()).

This table summarizes the argument values that should be used for each call:

Call OpenXR application OpenXR runtime
Instance::from_raw() drop_guard == Some drop_guard == None
Adapter::device_from_raw() handle_is_owned == true handle_is_owned == false
Device::texture_from_raw() drop_guard == Some drop_guard == None

The OpenXR runtime does not need drop guards since it's the client application that is resposible for managing the lifetime and drop order of the objects. The device does not use the drop_guard because not needed to enforce drop safety in the context of OpenXR.

Testing
None for now. I need ash-rs/ash#457 to be merged (and then wgpu to be updated with the new ash verison), which is orthogonal to this PR.

@zmerp
Copy link
Contributor Author

zmerp commented Aug 23, 2021 •
edited
Loading

There is still one thing that does not look right. When calling Device::texture_from_raw() with drop_guard == None (that is, the image handle is owned and destroyed by wgpu) wgpu does not create a memory block for it. Creating a memory block requires access to self, but the wgpu_hal::vulkan::Device is not clonable (and I was not able to make it clonable) and once it has been moved to wgpu::Device there is no easy way to get it back, not even a reference to it. For now I'll create and bind the image memory block externally, with the help of the ash::Device handle (that can be cloned).
Another option is to create the textures the intended/safe way but then again there is no easy way ofaccessing the underlying hal Texture.

@kvark kvark merged commit 1c086a5 into gfx-rs:master Aug 25, 2021
@zmerp
Copy link
Contributor Author

zmerp commented Aug 25, 2021 •
edited
Loading

Thank you for merging so quicky. This is the reference code for the runtime I'm working on. It's not tested yet. The code for creating the textures is needlessly complex and I would put this on pause until it is possible to access hal Texture from wgpu::Texture, which should be feasible after Hubs are removed from wgpu-core.

@zmerp zmerp mentioned this pull request Aug 29, 2021
Merged
@Neo-Zhixing Neo-Zhixing mentioned this pull request Sep 7, 2021
Closed
@zmerp zmerp mentioned this pull request Oct 14, 2021
Merged
kcking added a commit to kcking/bevy that referenced this pull request Jan 26, 2022
@kcking
wgpu validation still fails
96681d4 
look at gfx-rs/wgpu#1850 and
https://github.com/alvr-org/ALVR/blob/57f5ae138b071345b7603eb351b70391a17ae7b9/alvr/experiments/client/src/xr/openxr/graphics_interop.rs
for inspiration
kcking added a commit to kcking/bevy that referenced this pull request Jan 29, 2022
@kcking
wgpu validation still fails
ab7168e 
look at gfx-rs/wgpu#1850 and
https://github.com/alvr-org/ALVR/blob/57f5ae138b071345b7603eb351b70391a17ae7b9/alvr/experiments/client/src/xr/openxr/graphics_interop.rs
for inspiration
@memoryruins memoryruins mentioned this pull request Feb 10, 2022
Closed
@jerzywilczek jerzywilczek mentioned this pull request Aug 21, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kvark kvark kvark approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@zmerp @kvark